Modern tasks of a computer systems may require that a task, application, or process be started, run, and stopped hundreds of times. As a consequence, a computer system can quickly exhibit poor performance and suffer usage issues when it has to constantly recreate an environment in which to run the application. To alleviate this requirement pre-started jobs may be utilized.
A job is generally an execution path through an address space of a computer. The job may be as simple as a set of program instructions loaded in memory or as complex as an instance of an application or program. A pre-started job is a job loaded from a storage device, such as a hard disk drive or electronic memory, active in memory and ready for immediate use. With a pre-started job the computer system can quickly process information specific to that pre-started job without waiting for program load times, allocation of memory, configuration of the program, configuration of data, processor scheduling, or other overhead associated with starting the job from scratch. Generally speaking, pre-started jobs are active in memory in a “pool” and chosen by the computer system for a particular task by a job-selection algorithm. The management of pre-started jobs is known colloquially as “job pooling.” Conventional algorithms typically select the pre-started job for the task without performing monitoring of the status, state, or integrity of the pre-started job. Additionally, conventional algorithms may not be aware or concerned with previous faults, exceptions, fault conditions, poor performance, or failures of a pre-started job. This is especially true in an environment where multiple conventional algorithms are selecting pre-started jobs from the same pool and releasing them when done.
Once a pre-started job has finished with its task a conventional algorithm typically terminates the pre-started job or to return it to the pool of pre-started jobs. In a computer system constantly performing similar tasks, such as a web-server constantly serving Internet web pages to a computer, an algorithm will often return the pre-started jobs to the pool for future processing needs. Over time, however, a pre-started job may experience a fault condition such as a function check, an exception, failure, or performance impairment. A function check in a pre-started job may be issued if there is an incorrect input or output from the pre-started job. Similarly, an exception of a pre-started job may result from an illegal operation of the pre-started job. A failure of a pre-started job typically results in the pre-started job being terminated and the job started again, then that newly started job assigned to the pre-started job pool.
In a conventional job selection algorithm, performance impairments in a pre-started job typically remain undetected, thus slowing the computer system as it processes a task with an impaired pre-started job. After the task in the impaired pre-started job is processed, if it finishes, a conventional algorithm still typically returns the impaired pre-started job to the pool of pre-started jobs. In this way, the impaired pre-started job may again be selected by a conventional job-selection algorithm without addressing the performance impairment.
When a conventional algorithm determines that there has been a function check, exception, pre-started job failure, or poor performance of a pre-started job it typically notifies the computer system. Upon being notified of the error, the computer system typically terminates the affected pre-started job, starts the job again, and puts the newly started job in the pre-started job pool. This process of termination and initiation of a job ultimately taxes the computer system and may leave the cause of the function check unresolved. In this way, conventional algorithms only address the outcome of a fault condition and not its origin.
After a conventional algorithm determines there has been a fault condition in a pre-started job there is typically no way to stop operation of the pre-started job and debug the cause of the fault condition. When the pre-started job is a part of mainline code it is impossible for a conventional algorithm to insert a trap in the code because the mainline code is fixed and cannot be changed. Similarly, in the event the pre-started job that has experienced the fault condition is unknown, it is impossible for a conventional algorithm to insert a breakpoint into the code of the pre-started job. In this way, conventional processing of the pre-started job does not allow for debugging of the cause of the fault condition of the pre-started job.
Consequently, there is a need for an improved manner of debugging pre-started jobs.